The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
A new device that is installed in a network may cause network communication problems. For example, if users experience problems with connecting to the network after a new device joined the network's fabric, then the new device is most likely suspected to cause the connectivity issues.
Regardless of whether the suspicion is substantiated or not, devices newly installed in a network and devices reconfigured in the network require a comprehensive testing in the network environment to ensure that the new device seamlessly interacts with the network. Such testing often requires troubleshooting.
Network troubleshooting may be a very complex and time consuming process. In some cases, troubleshooting each individual device and each individual network segment in a network environment may be impractical in a reasonable time. Nevertheless, there might be a need to efficiently identify the source of connectivity problems and to determine for example, whether a particular device or a link to the particular device causes the problems.
Some of the troubleshooting approaches rely on commands such as traceroute, ping or echo. However, traceroute, ping and echo may be insufficient to identify the specific network component that causes the problem. For example, if a particular device is nonresponsive to traceroute, it may be difficult to determine whether the particular device itself is malfunctioning, or whether the link to the particular device or a device along that link is malfunctioning. Furthermore, the traceroute, ping and echo tests may be limited to a specific protocol and/or port, and thus they may be unable to test the actual end-to-end availability of a particular hosted service.
Due to the type and complexity of the tasks performed by a security device, the security device may be the first to blame when a user cannot connect to a server. Because the security device performs security checks to determine whether a data packet is valid, and may drop the packet without notifying the packet's sender when the packet is invalid, troubleshooting of the connection between the customer and the service provider becomes a multifarious task.
From a perspective of a service provider, network troubleshooting may be quite expensive and time consuming. For example, the overhead required to train and provide a skilled staff for processing service calls and resolving network connectivity issues may be considerable.